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Task  1:  Managing  Unarticulated  Value:  Changeability  in  Multi- Attribute  Tradespace 
Exploration 

Managing  Unarticulated  Value:  Changeability  in  Multi- Attribute 

Tradespace  Exploration 

Adam  M.  Ross,  MIT  ESD  PhD  Candidate 

This  work  extends  the  value-centric,  decision  theoretic  tradespace  exploration  framework 
developed  by  the  author  in  his  Masters  thesis  by  adding  an  expanded  understanding  of  value, 
dynamic  contexts,  and  system  change. 1 

Classes  of  Value:  From  Articulated  to  Unarticulated 

Spectrum  of  Perceived  Needs 

The  value  created  by  a  developed  system  can  often  be  placed  into  two  categories:  driving  need, 
or  derived  need.  Driving  need  exists  before  the  system  is  developed  and  provides  the  impetus  for 
the  development  effort.  Derived  need  emerges  from  the  system  in  operation,  revealing  itself  to 
those  affecting  and  affected  by  the  system.  From  the  perspective  of  the  initial  system  Designer 
who  seeks  to  create  a  valuable  system,  the  driving  need  is  often  expressed  in  terms  of  objectives 
and  requirements,  while  the  derived  need  is  expressed  through  marketing  research  and  business 
strategy.  A  key  difficulty  presented  by  derived  needs  to  the  Designer  is  the  uncertainty 
associated  with  it.  Instead  of  viewing  the  needs  in  terms  of  these  two  categories  of  driving  and 
derived,  a  more  useful  taxonomy  is  to  consider  value  as  a  spectrum  of  needs  from  articulated  to 
unarticulated. 

Imagine  there  exists  a  set  of  needs  for  every  system  stakeholder  past,  present,  and  future.  If  a 
system  designer  could  know  these  needs  and  provide  a  way  for  the  system  to  meet  them  in  the 
correct  manner  at  the  correct  time,  such  a  system  would  be  valuable  indeed.  Articulated  needs 
are  those  needs  from  the  set  that  have  been  explicitly  communicated  to  the  system  Designer. 
Unarticulated  needs  are  those  that  have  not  yet  been  explicitly  communicated.  The  reasons  for 
the  unarticulated  needs  are  various,  but  the  goal  of  the  Designer  is  the  same:  discover  as  much  of 
the  unarticulated  needs  as  possible,  or  at  least  make  it  so  the  system  can  meet  them  when  they 
are  revealed  or  discovered. 

Unarticulated  needs  include  those  that  cannot  be  explicitly  communicated  because  the 
stakeholder  has  forgotten  them  for  the  moment,  or  does  not  yet  know  them,  or  cannot  quite 
express  them  in  words.  Unarticulated  needs  also  include  needs  that  stakeholders  do  not  say 
because  the  stakeholder  has  assumed  that  the  Designer  is  already  aware  of  them.  Additionally, 
unarticulated  needs  include  those  needs  the  stakeholder  will  not  say  because,  for  whatever 
reason,  those  needs  must  remain  secret.  The  reasons  for  the  unarticulation  may  change  over  time 
as  well. 

The  process  of  revelation  or  discovery  of  unarticulated  needs  can  incorporate  several  methods 
including  personal  reflection,  conversations  with  mediators,  experience  with  the  system, 
interactions  with  the  system  context,  or  seeing  the  system  in  a  changed  or  new  context. 


Ross,  Adam  M.  Multi-Attribute  Tradespace  Exploration  with  Concurrent  Design  as  a  Value-Centric  Framework  for  Space  System  Architecture 
and  Design.  Dual-SM,  Aeronautics  and  Astronautics,  and  Technology  and  Policy.  Massachusetts  Institute  of  Technology:  2003. 
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Role  of  Dynamic  Context 

A  common  approach  in  system  design  is  to  optimize  the  system  according  to  a  set  of  objectives. 
Finding  the  “best”  system  is  the  goal  of  such  an  exercise.  The  technocratic  optimization 
approach  works  well  and  will  provide  the  “best”  answer  only  if  the  assumptions  of  the  analysis 
hold  true  in  the  real  world.  Unfortunately,  often  such  is  not  the  case.  A  fundamental  assumption 
in  the  optimization  approach  is  the  assumption  of  correct  objective  functions.  If  the  objective 
functions  change  with  time,  no  guarantee  exists  that  the  system  will  remain  “best”.  In  fact,  recent 
research  suggests  that  such  overly  optimized  designs  are  quite  fragile  in  the  face  of  changing 
objectives  or  context. 

Related  to  the  assumption  of  static  objectives  is  that  of  static  context.  Design  for  robustness  is  an 
approach  to  try  to  find  design  options  that  will  continue  to  perform  well  in  the  face  of  changing 
operational  environments.  The  context  includes  not  only  the  operational  environments  however, 
but  also  the  stakeholder  sets,  the  expectations  of  the  system,  the  resources  available  to  the 
system,  the  competition  for  the  system,  and  any  other  exogenous  factor  that  affects  the  perceived 
value  of  the  system.  Many  of  these  factors  are  not  considered  during  an  optimization  exercise 
beyond  the  technical  environment,  though  they  may  significantly  affect  the  perceived  value  of 
the  system.  An  example  of  such  a  dangerous  omission  is  a  technical  optimization  of  a  satellite- 
based  communication  system,  ignoring  terrestrial  competition,  such  as  the  fate  suffered  by  the 
Iridium  and  Globalstar  systems. 

In  the  military  regime,  high-level  objectives  may  remain  relatively  static,  such  as  ‘defend  some 
region,’  or  ‘provide  infonnation  about  some  region.’  As  these  objectives  are  decomposed, 
however,  assumptions  begin  to  creep  in,  which  also  inherently  includes  the  possibility  for 
change.  An  example  is  the  emerging  usage  of  UAVs  for  both  rapid  reconnaissance  and 
interdiction,  or  the  growing  civil  dependence  on  the  military  GPS  system.  On  even  shorter  time 
scales,  targets  of  opportunity  arise  and  systems  must  react  quickly  in  order  to  deliver  value,  even 
if  the  desired  usage  does  not  match  the  intended  usage.  In  order  to  capture  value,  as  it  emerges 
from  unarticulated  to  articulated  space,  systems  must  be  designed  for  changeability. 
Changeability  Defined 

Changeability  relates  fundamentally  to  the  often-discussed  system  properties  of  flexibility, 
adaptability,  scalability,  and  robustness,  among  others.  These  properties  all  have  one  thing  in 
common:  they  relate  to  how  the  system  can  change  with  time. 

Two  related  tensions  through  the  value  discussion  are  the  interplay  between  the  stakeholders 
with  their  need,  and  the  Designers  with  their  system.  The  need  of  the  stakeholders  can  be 
captured  in  the  value-space  perspective  on  the  system.  The  system  of  the  Designer  can  be 
captured  in  the  real-space  perspective  on  the  system.  The  key  differentiator  between  these  spaces 
is  that  the  real-space  represents  tangible  elements  of  the  system  that  can  be  actively  manipulated 
by  the  Designer  (design  variables),  while  the  value-space  represents  intangible  or  tangible 
aspects  of  the  system  from  which  stakeholders  derive  value  (attributes). 

Real-space  ilities 

The  system  properties  that  relate  to  the  real-space  perspective  are  flexibility,  adaptability,  and 
rigidity.  Flexibility  is  the  ability  of  the  system  to  be  changed  by  an  external  agent.  Adaptability  is 
the  ability  of  the  system  to  be  changed  by  an  internal  agent.  Rigidity  is  the  inability  of  the  system 
to  be  changed.  The  external  versus  internal  agent  boundary  is  determined  by  the  boundary  of  the 
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system.  The  ability  versus  inability  for  system  change  is  detennined  by  the  boundary  of  ‘cost’ 
(money  or  time,  or  other  resource)  that  is  acceptable  to  the  desirer  of  change. 

Value-space  ilties 

The  system  properties  that  relate  to  the  value-space  perspective  are  scalability,  modifiability,  and 
robustness.  Scalability  is  the  ability  of  the  system  to  have  the  level  of  a  currently  displayed 
attribute  changed.  Modifiability  is  the  ability  of  the  system  to  have  the  currently  displayed 
attribute  set  changed,  including  the  addition  or  deletion  of  new  or  old  attributes.  Robustness  is 
the  ability  of  the  system  to  continue  to  deliver  value  in  the  face  of  a  changing  context. 

Forming  ility  statements 

In  order  to  properly  pose  the  question  “is  my  system  flexible?”  it  is  necessary  to  formulate  a 
rigorous  statement.  First,  the  subjective  scale  for  acceptable  resource  usage  must  be  set 
(boundary  of  ability  versus  inability  to  change).  Second,  the  origin  of  change  must  be  chosen 
(will  it  be  an  external  or  internal  or  no  agent?).  Third,  the  value-effect  change  must  be  chosen 
(level  or  attribute  set,  or  constant  value?).  An  example:  Is  my  system  flexibly  scalable  in 
bandwidth  for  less  than  $10M  and  less  than  three  months?  This  formulation  can  be  answered 
more  meaningfully  than  the  more  nebulous  “is  my  system  flexible?” 

A  Method  to  Assess  System  Changeability 

Once  the  philosophy  of  changeability  has  been  related  and  understood  by  the  Designer,  analysis 
techniques  must  be  augmented  in  order  to  assess  the  changeability  of  system  design  options. 

Including  Transition  Paths 

Designing  ‘in’  the  changeability  of  the  design  variables  (real-space  change)  includes  the  notion 
of  transition  paths.  A  transition  path  is  the  mechanism  for  changing  a  system  from  one  state  to 
another  state.  The  time  and  cost  for  the  change  is  highly  dependent  on  the  mechanism  employed 
(a  path  dependence  for  the  system  transitions).  When  a  designer  is  enumerating  the  space  of 
system  options  (tradespace),  part  of  the  exercise  must  include  consideration  for  change.  Thus,  in 
addition  to  creating  the  design  variables  (the  quantification  of  the  system  designs),  the  Designer 
also  creates  transition  mechanisms,  or  rules.  These  rules  specify  the  allowed  changes  from 
design  to  design  and  provide  a  mechanism  for  calculating  the  ‘cost’  for  following  the  rule. 

An  example  of  applying  such  an  approach  is  the  following:  Consider  a  system  design  for  a 
satellite  in  low  earth  orbit  whose  orbit  must  be  changed,  for  whatever  reason,  but  whose  fuel 
must  remain  at  pre-orbit  change  levels.  Possible  transition  rules  include:  1)  burning  on-board  fuel 
to  maneuver  to  a  new  orbit,  followed  by  an  on-orbit  refuelability  modification,  and  on-orbit 
refueling  to  bring  the  on-board  fuel  back  to  pre-burn  levels,  2)  adding  the  refuelability 
modification  prior  to  launch,  burning  the  on-board  fuel  to  maneuver  to  a  new  orbit,  followed  by 
on-orbit  refueling  to  bring  the  on-board  fuel  back  to  pre-burn  levels,  3)  using  a  space  tug  to  grab 
the  satellite,  move  it  to  the  new  orbit,  and  release,  4)  purchase  a  new  satellite  that  is  inserted  into 
the  correct  new  orbit.  Figure  1  shows  how  these  four  path  mechanisms  result  in  different  costs 
for  having  a  system  change  from  the  same  state  1  to  state  2.  The  points  are  plotted  in  terms  of 
each  state’s  incremental  cost  over  the  previous  state  (AC)  and  its  perceived  value  (Utility,  U) 
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Figure  1  Example  Transition  Paths  for  Changing  from  State  1  to  State  2  (Perigee  lowering) 

Technology  and  creativity  are  the  key  factors  affecting  the  creation  of  transition  mechanisms.  In 
fact,  the  process  of  trying  to  develop  transition  mechanisms  can  elucidate  key  areas  where 
technology  development  can  greatly  increase  the  changeability  of  a  design  (by  either  enabling 
new  transition  paths,  or  reducing  the  ‘cost’  of  an  existing  path.) 

The  creation  of  Orbital  Express,  or  other  standardized  on-orbit  servicing  architectures,  is  an 
explicit  effort  to  create  transition  mechanisms  (using  the  standard  servicing  architecture)  at  lower 
cost  and  time,  thereby  increasing  the  changeability  of  systems  that  adhere  to  the  architecture 
standards.  The  reduced  transition  costs  for  the  serviceable  systems  come  at  the  price  of  increased 
development  costs.  Finding  the  proper  balance  between  initial  cost  increases  and  reduced 
changeability  costs  can  be  analyzed  in  a  tradespace  analytic  framework.  Non-serviceable  systems 
can  be  compared  on  the  same  utility-cost  plots  to  serviceable  systems.  All  other  things  being 
equal,  a  serviceable  system  will  probably  have  higher  cost  at  a  fixed  utility,  or  lower  utility  at  a 
fixed  cost.  The  benefit  for  a  serviceable  system,  however,  will  be  captured  when  adding  in  the 
potential  transition  paths  for  that  system  in  the  tradespace. 
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Computers  can  automate  the  path  analysis  to  enable  large  tradespace  exploration  by 
incorporating  the  idea  of  transition  rules.  The  rules  are  automatically  applied  to  the  tradespace  in 
order  to  create  a  tradespace  network  linked  through  transition  paths.  More  changeable  options 
will  manifest  more  possible  transition  paths  to  other  designs.  The  “costs”  of  these  transitions  are 
embedded  in  the  arcs  connecting  the  design  options.  In  order  for  this  analysis  to  be  truly  useful, 
however,  the  temporal  context  for  the  changeability  analysis  must  be  added. 

Adding  the  Timeline 

Each  of  the  static  analyses  done  prior  can  be  envisioned  to  be  a  single  frame  of  a  long  movie, 
which  strung  together,  can  form  a  dynamic  picture  of  the  system.  An  Epoch  is  the  single  frame 
short  run  analysis,  during  which  a  scenario  is  defined.  The  objectives,  constraints,  stakeholder 
set,  duration,  and  boundary  conditions  are  specified.  The  previous  example  of  changeable 
tradespace  analysis  can  be  conducted  during  each  Epoch.  When  one  of  the  criteria  of  an  Epoch 
changes,  a  new  one  should  be  created  and  analyzed  (for  example,  the  change  of  a  policy,  market 
conditions,  stakeholder  set,  or  objectives).  A  string  of  Epochs  with  satisfied  boundary  conditions 
(continuity  of  states  across  the  boundary)  forms  a  system  Era.  The  system  Era  is  the  long  run 
picture  of  the  system.  Figure  2  shows  a  notional  System  Era  consisting  of  n  Epochs. 


Time 


Figure  2  System  Epochs  and  System  Era:  The  System  Change  Timeline 

Changeability  can  be  assessed  during  an  Epoch  or  across  an  Era,  depending  on  the  desired 
system  property  to  be  determined  (i.e.  scalability  in  bandwidth  in  the  short  run  or  long  run). 

Example  Application  to  On-orbit  Servicing 

As  an  example  of  the  proposed  analysis  framework,  suppose  a  system  designer  is  planning  to 
develop  a  new  space  system.  Proposed  design  options  include  traditional  designs,  as  well  as  new 
standardized  Orbital  Express  accessible  designs,  which  can  be  more  readily  changed.  Such 
changes  include  restoring  and  upgrading  capabilities  of  the  system.  Figure  3  depicts  a  time-series 
tradespace  analysis  of  the  problem.  Each  utility-cost  tradespace  shows  the  Designer  various 
design  options  in  terms  of  their  perceived  value  (Utility)  and  cost.  The  “optimal”  designs  are 
those  that  deliver  maximum  value  at  a  given  cost.  Both  serviceable  (red)  and  non-serviceable 
(light  blue)  designs  are  compared.  Over  time,  the  perceived  value  of  the  system  may  change, 
moving  the  “optimal”  designs  into  sub-optimal  regions  of  the  tradespace.  The  figure  shows  three 
notional  time  periods,  differentiated  by  differing  value  functions.  Serviceable  designs  can  be 
transitioned  to  other  designs  at  relatively  low  cost,  especially  as  compared  to  traditional  non- 
serviceable  designs,  thereby  enabling  the  system  to  recapture  lost  value  over  time.  Given  the 
ability  to  move  toward  the  higher  value  solutions  over  time,  the  Designer  selects  a  serviceable 
option  and  compares  its  time-varying  value-delivery  to  a  similar  non-serviceable  option. 
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Serviceable 


Not  Serviceable 


Figure  4  Temporal  Comparison  of  Serviceable  vs.  Non-serviceable  Systems 


Figure  4  gives  another  view  of  the  dynamic  recapturing  of  value  allowed  by  a  serviceable  design. 
Incremental  costs  are  incurred  by  the  serviceable  system  each  time  a  servicing  mission  is 
performed  (a  system  change).  While  the  total  system  cost  for  a  changeable  system  will  most 
likely  exceed  that  of  a  static  system,  the  total  system  benefit  may  warrant  such  an  approach.  (Iso¬ 
benefit  comparisons  of  cost,  or  iso-cost  comparisons  of  benefit  will  yield  even  more  insights  into 
which  approach  may  be  better.)  Given  this  analysis,  the  Designer  next  seeks  to  see  how  a 
changeable  system  might  be  depicted  over  its  system  timeline. 

Figure  5  gives  an  example  of  a  system  timeline  for  a  serviceable  system.  Such  a  system  has  both 
variable  value  delivery  due  to  performance  changes,  as  well  as  due  to  changing  value  perceptions 
(e.g.  new  markets,  targets  of  opportunity,  etc.).  Servicing  events  enable  the  system  to  both 
capture  and  recapture  value  in  the  dynamic  context. 
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Figure  5  System  Timeline  Showing  the  Effects  of  On-orbit  Servicing  on  a  System  (notional) 


Systems  that  are  designed  for  servicing  (changeability)  will  likely  have  lower  physical  change 
costs  than  traditional  systems  and,  by  the  definitions  given  above,  will  more  likely  be  perceived 
as  flexible  (ie,  changeable.)  Designers  of  Orbital  Express  should  keep  in  mind  the  subjective 
thresholds  for  acceptable  change  costs  for  potential  decision  makers.  Even  if  the  costs  are  less 
than  traditional  designs,  if  those  costs  are  higher  than  the  threshold,  servicing  will  not  occur  and 
the  system  will  be  perceived  as  rigid.  Scenario  analyses  of  likely  value-perception  changes 
should  be  done  to  detennine  whether  physical  alteration  of  the  satellite  is  the  most  cost-effective 
mechanism  for  changing  a  system.  It  is  possible  that  the  most  value-generating  changes  could 
come  about  through  clever  functional  allocation  at  the  time  of  system  design,  coupled  with  low- 
cost  software,  or  other  non-physical  upgrades. 

Discussion 

One  implication  of  the  framework  is  that  changeability,  including  the  concept  of  flexibility,  does 
not  necessarily  require  physical  change.  Change  is  desired  in  order  to  match  the  system  with 
revealed  unarticulated  value  (i.e.  with  the  articulation  of  needs  over  time).  The  need  that  is 
articulated  may  already  coincide  with  existing  system  capabilities,  or  perhaps  with  only  slightly 
modified  system  capabilities.  This  suggests  that  systems  with  a  more  generic  set  of  capabilities 
may  have  more  potential  value,  since  those  capabilities  can  be  recombined  into  a  potentially  very 
large  set,  which  may  have  a  higher  likelihood  of  overlapping  revealed  value. 

Realizable  changeability  must  address  the  ‘cost’  of  matching  system  capabilities  to  revealed 
value.  Concepts  such  as  modularity  and  standards  are  specific  approaches  to  reduce  the  potential 
‘cost’  of  a  change  at  the  moment  of  change  execution.  A  common  complaint  of  these  approaches 
is  their  upfront  investment  cost  with  no  guarantee  of  use  (unused  change  options).  The  future  is 
not  necessarily  predictable,  so  the  possibility  of  unused  options  will  inevitably  remain. 
Nonetheless,  change  is  predictable  in  that  it  will  happen  at  some  point.  The  role  of  a  good  system 
designer  is  to  recognize  when  it  is  worthwhile  to  build  in  the  ability  for  the  system  to  change 
with  its  context  in  order  to  remain  of  value.  The  analysis  methods  mentioned  above  will  help  the 
Designer  in  system  design  trade  studies  develop  lower  ‘cost’  opportunities  for  both  short  and 
long  term  changeability,  both  before  and  after  the  system  is  fielded. 
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Task  1:  Research  Title:  On-Orbit  Serviceability  of  Space  System  Architectures 

Student:  Matthew  Richards 

Master  of  Science  degrees  in  Aerospace  Engineering,  Technology  and  Policy 


Introduction 

Space  systems  are  critical  to  maintaining  international  security,  economic  progress,  and  safety 
from  natural  disasters.  Unfortunately,  the  current  paradigm  of  space  system  conceptual  design, 
acquisition,  and  operation  is  failing.  Traditional  systems  engineering  processes  are  not 
applicable  to  the  conceptual  design  of  system-of-systems  into  which  satellites  are  increasingly 
integrated.  Space  system  acquisitions  are  often  characterized  by  tremendous  cost  overruns  and 
schedule  slips.  And  satellite  operations  are  tightly  constrained  by  the  physical  inability  to  access 
hardware  post-launch.  There  is  a  need  for  holistic  reform  that  targets  the  entire  space  enterprise 
rather  than  locally  optimal  solutions.  Most  fundamentally,  research  is  needed  to  overcome  the 
current  deficiencies  of  space  system  conceptual  design,  acquisition,  and  operation  by  proposing 
and  demonstrating  the  value  of  a  more  flexible  approach. 

This  research  addresses  these  problems  by  assessing  the  amenability  of  satellites  to  on-orbit 
servicing  and  exploring  the  value  of  architecture  frameworks  as  tools  for  completing  such 
analyses.  On-orbit  servicing  (OOS)  has  been  proposed  to  enable  satellite  operators  physical 
access  to  their  systems  after  launch — addressing  the  established  paradigm  of  inflexible, 
unresponsive  space  operations.  Existing  OOS  studies  focus  on  the  development  of  servicing 
provider  architectures  or  case  studies  in  customer  valuation  of  various  servicing  missions.  The 
focus  of  this  research  is  on  the  physical  amenability  to  OOS — or  serviceability — of  all  space 
system  architectures. 


Figure  6.  Artistic  representation  of  servicing  vehicle 


The  goals  of  this  research  are  two-fold:  contribute  theoretically  by  proposing  a  generalized 
process  for  assessing  system  serviceability  and  contribute  practically  by  testing  this  process 
through  application  to  all  operational  satellite  systems.  Specific  research  objectives  include: 

1)  Characterize  the  current  state  of  architecture  frameworks 

2)  Develop  a  framework  to  describe  the  serviceability  systems 
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3)  Categorize  space  systems  within  the  framework 

4)  Identify  architectural  elements  across  space  systems  that  make  them  physically  amenable 
to  on-orbit  servicing 

5)  Investigate  political,  legal,  operational,  and  financial  context  for  OOS 
Development  of  an  Ordered  Taxonomy  of  Space  System 

Architecture  frameworks  for  physical  systems  have  been  developed  by  the  Department  of 
Defense  and  the  UK’s  Ministry  of  Defense  to  add  structure  to  the  problem  of  designing  and 
acquiring  system-of-systems.  By  characterizing  the  form,  function,  and  rules  governing  systems, 
architecture  frameworks  serve  as  a  communication  tool  to  stakeholder  communities  with 
different  views  of  the  system  and  facilitate  comparative  evaluation  across  architectures.  This 
research  will  employ  and  potentially  propose  improvements  to  the  Department  of  Defense 
Architecture  Framework  (DoDAF)  to  conduct  serviceability  assessments  across  space  systems. 


Figure  7.  DoDAF  OV-1:  Fligh-Level  Operational  Concept  Graphic,  Flubble  Space  Telescope 


The  application  of  architecture  frameworks  to  physical  systems  is  relatively  new.  The  UK’s 
Ministry  of  Defense  Architecture  Framework  (MoDAF)  is  still  in  development  while  the  DoDAF 
in  its  current  form  is  a  series  of  templates  describing  static  products. 

Methodology  to  Assess  Physical  Amenability  of  Satellites  to  On-Orbit  Servicing 
This  research  will  propose  a  generalized  process  for  assessing  serviceability.  Work  on  this 
methodology  is  an  on-going  activity.  Currently,  complexity  theory  is  being  consulted  as  a 
potential  theoretical  basis  for  identifying  fundamental  attributes  of  servicing  systems.  Lessons 
learned  from  servicing  other  systems  which  are  technologically  enabled  and  hard  to  access — 
such  as  off-shore  oil  platforms — will  also  be  explored.  Flypothesized  fundamental  attributes  of 
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servicing  include  Knowledge,  Scale,  Precision,  and  Timing  requirements  across  four  servicing 
activities:  Rendezvous,  Acquire,  Access,  and  Add  Value. 


Figure  8.  Mapping  of  on-orbit  servicing  functional  decomposition  to  physical  systems 


Upon  establishing  a  “menu”  of  serviceability  metrics,  potential  servicing  mission  areas  will  be 
functionally  decomposed.  The  figure  above  displays  a  “spiral  one”  iteration  of  high-level 
servicing  functions  mapped  to  lower-level  capabilities  and  traced  to  specific  applications.  This 
research  will  propose  a  serviceability  function  for  each  servicing  mission  area  defined  above, 
deriving  input  variables  from  the  “menu”  of  serviceability  metrics. 

In  order  to  maximize  the  number  of  satellites  assessed  for  physical  amenability  to  on-orbit 
servicing,  global  satellite  databases  will  be  consulted.  Of  particular  note  is  the  Union  of 
Concerned  Scientists  (UCS)  Satellite  Database  which  contains  information  on  the  over  800 
operational  satellites  in  orbit  around  the  Earth.  Technical  information  about  each  satellite 
includes  mass,  power,  launch  date,  and  expected  lifetime  in  addition  to  orbital  elements,  user 
information,  and  general  purpose.  Our  preliminary  assessment  is  that  the  UCS  Satellite  Database 
will  be  a  useful  source  of  input  data  to  a  low-fidelity  model  of  serviceability — serving  as  a  filter 
to  down  select  to  a  short  list  of  serviceable  satellites.  High-fidelity  models  will  be  employed  to 
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assess  serviceability  across  the  short  list  of  satellites  deemed  serviceable.  We  will  attempt  to 
employ  the  static  views  of  space  systems  captured  in  architecture  frameworks  as  the  input  data  to 
these  higher  fidelity  models. 

Architecting  for  Satellite  Servicing:  Prescriptive  Technical  Considerations 
The  key  output  of  this  research  will  be  a  set  of  architectural  heuristics  for  designing  serviceable 
spacecraft.  We  have  hypothesized  that  for  satellites  to  be  serviceable,  the  servicing  provider  will 
have  high  levels  of  knowledge  of  the  state  of  the  system  ( e.g high-fidelity  telemetry, 
configuration  control  during  assembly,  orbits  with  ‘less’  radiation  and  thermal  cycling,  orbits 
where  the  satellite  might  be  inspected).  Serviceable  satellites  might  also  minimize  precision 
required  in  servicing  activities  through  a  modular  architecture  and  docking  interfaces  which 
guide  autonomous  rendezvous  and  docking. 
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Figure  9.  Collision  probabilities  for  various  geosynchronous  servicing  vehicle  parking  orbit  altitudes 


In  addition  to  prescribing  architectural  features  that  make  satellites  more  serviceable,  this 
research  will  also  consider  technical  issues  associated  with  the  servicing  vehicle.  For  example, 
estimates  of  collision  probabilities  for  a  near-GEO  servicing  vehicle  parking  orbit  were 
calculated  using  the  Poisson  distribution  and  principles  of  the  kinetic  theory  of  gases  (see  above). 
A  ten  year  servicing  vehicle  lifetime  was  assumed.  The  velocity  change  (AV)  requirements  to 
reach  geosynchronous  altitude  vary  between  1.8  m/s  and  16.6  m/s  depending  on  the  altitude 
change  necessary.  Propulsion  choice  ( i.e .,  chemical  vs.  electric)  affects  the  time  requirements 
for  transfer  from  parking  to  geosynchronous  orbit.  The  time  required  for  transfer  via  electric 
propulsion  can  range  to  as  high  as  180  days,  depending  on  the  acceleration  produced  by  the 
engine,  while  the  transfer  time  via  chemical  propulsion  is  approximately  12  hours  over  the  range 
of  possible  parking  orbit  altitudes. 

The  advantage  of  low  thrust  electric  propulsion  systems  with  specific  impulses  exceeding  1,000 
seconds  is  a  combination  of  reduced  tug  mass  and  increased  AV  capability.  On  the  other  hand, 
because  of  the  slow,  spiraling  trajectory  followed  when  changing  altitude,  the  servicing  vehicle 
would  orbit  repeatedly  at  altitudes  where  the  probability  of  collision  is  heightened  slightly.  In 
addition,  the  power  requirement  for  electric  propulsion  systems,  ranging  from  0.5  kW  up  to  4.5 
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kW,  is  much  higher  than  for  chemical  propulsion.  It  should  be  noted  that  even  if  a  servicing 
vehicle  were  equipped  with  electric,  chemical  thrusters  would  still  be  required  for  maneuvers  in 
close  proximity  to  the  target  spacecraft. 

Political,  Legal,  and  Financial  Challenges  of  On-Orbit  Servicing 

This  research  also  addresses  the  political,  legal,  and  financial  context  of  on-orbit  servicing. 
Although  servicing  technology  will  likely  be  developed  in  accordance  with  U.S.  Space 
Transportation  Policy,  the  actual  deployment  of  such  a  system  is  uncertain  due  to  the  nature  of 
its  potential  customers.  The  primary  policy  challenge  facing  implementation  of  a  servicing 
system  is  gaining  the  trust  of  satellite  operators.  This  challenge  is  particularly  great  in  the  Air 
Force,  where  program  managers  of  national  space  assets  are  traditionally  risk-adverse  and  might 
hold  a  short-term  outlook  of  satellite  operations  given  that  the  tenure  of  many  military  program 
managers  is  less  than  two  years.  To  overcome  this  barrier,  it  might  be  necessary  to  review  the 
incentive  structure  of  Air  Force  program  managers.  Lengthening  tours-of-duty  of  program 
managers  or  providing  career  incentives  to  program  managers  who  extend  mission  life  of  space 
assets  are  possible  improvements.  Another  alternative  is  to  make  mission  life  extension  a 
requirement  for  high-value  space  assets. 


Figure  10.  Meeting  the  implementation  challenges  of  on-orbit  servicing 


Legal  constraints  for  space  tug  operations  can  be  divided  into  two  categories:  customary 
international  law  and  national  law.  Since  its  establishment  in  1959,  the  United  Nations 
Committee  on  Peaceful  Uses  of  Outer  Space  (COUPOS)  has  launched  five  major  international 
legal  instruments  that  form  the  bulk  of  laws  governing  space.  Key  principles  pertinent  to 
satellite  servicing  include  a  state’s  right  to  maintain  jurisdiction  and  control  over  space  objects 
(regardless  of  condition),  registration  obligations,  and  on-orbit  liability.  Other  customary 
international  space  laws  are  derived  from  bilateral  arms  control  treaties  between  the  U.S.  and 
U.S.S.R.  National  legal  principles  relevant  to  space  tug  operations  include  U.S.  criminal  law 
pertaining  to  interference  with  the  operation  of  a  satellite. 

Government-commercial  cost  sharing  precedents  exist  for  space  assets  and  other  shared 
resources.  However,  it  is  unclear  what  type  of  financing  model  servicing  operations  will  assume 
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or  how  the  issue  of  proprietary  development  will  impact  financing.  The  Commercial  Space 
Competitiveness  Act  of  1992  authorized  NASA  and  other  agencies  to  make  their  facilities 
available  to  private  entities.  This  provides  a  number  of  options  for  ownership,  operation,  and  use 
of  a  satellite  servicing  system. 
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Task  2:  The  OOS  studies  in  a  monograph;  an  example 


Running  Example  two:  general  purpose  orbit  transfer  and  servicing  vehicle  (SpaceTug)1 

The  SpaceTug  project  was  carried  out  by  a  team  of  undergraduate  and  graduate  students, 
postdoctoral  and  staff  researchers,  and  faculty  in  a  single  summer.  It  was  the  first  use  of  the 
MATE-CON  method  under  contract  with  a  government  sponsor.  The  aim  was  to  explore  the 
tradespace  of  possible  orbit  transfer  and  service  vehicles,  looking  for  potential  cost-effective 
capabilities  that  might  be  of  national  interest. 

The  space  tug  concept  is  for  a  vehicle  or  vehicles  to  loiter  in  earth  orbit  and  carry  out  multiple 
missions  involving  visiting  existing  assets  in  orbit  and  observing,  servicing,  or  moving  them. 

The  project  was  motivated  by  a  general  interest  in  such  systems  as  a  national  capability,  and  the 
historically  poor  results  when  proposing  such  systems  for  specific  missions  without  looking  at 
the  wider  tradespace  of  possible  uses  and  designs. 

Figure  1 1  shows  the  MATE  process  as  carried  out  for  the  SpaceTug  project.  The  project  was 
scoped  widely,  as  the  possible  uses  for  such  a  system  are  not  currently  know.  A  somewhat 
simplified  version  of  the  MATE  method  was  used.  The  method  was  adapted  in  response  to 
difficulties  including  the  lack  of  an  immediate  customer  and  a  very  open  design  space.  The 
customer  utilities  were  handled  parametrically  to  understand  the  sensitivities  of  the  tradespace  to 
ranges  of,  and  changes  in,  user  needs.  The  analysis  was  done  at  a  high  level,  using  low-fidelity 
models,  but  covering  a  large  range  of  possible  designs. 

The  capabilities  of  a  SpaceTug  vehicle  determined  to  be  useful  to  a  potential  user  include:  (1) 
total  delta-V  capability,  which  determines  where  the  SpaceTug  can  go  and  how  far  it  can  change 
the  orbits  of  target  vehicles;  (2)  mass  of  observation  and  manipulation  equipment  carried,  which 
determines  at  a  high  level  what  it  can  do  to  interact  with  targets,  referred  to  here  as  its  capability, 
and  (3)  response  time,  or  how  fast  it  can  get  to  a  potential  target  and  interact  with  it  in  the  desired 
way. 

These  attributes  are  translated  into  a  single  utility  function.  In  the  absence  of  real  users  from 
which  to  collect  more  sophisticated  functions,  it  was  decided  that  a  simple  function  that  could  be 
explored  parametrically  was  most  appropriate.  The  utility  was  a  weighted  sum  of  utilities  from 
the  three  attributes  above,  with  the  weights  being  considered  parametically.  The  figure  shows  a 
single-attribute  utility  for  Delta-V.  In  this  case,  utility  is  assumed  to  increase  linearly  with  delta- 
V,  with  diminishing  returns  above  the  levels  necessary  to  do  Low  Earth  Orbit  (LEO)  to 
Geosynchronous  Earth  Orbit  (GEO)  transfers. 

A  set  of  design  variables  (in  MATE  parlance,  a  design  vector)  was  selected  to  represent  possible 
tug  vehicles.  The  following  variables  were  selected:  (1)  observation  and  manipulator  system 
mass;  (2)  propulsion  type;  and  (3)  mass  of  fuel  carried. 
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For  the  simulations,  simple  parametric  relationships  and  design  rules  were  used  to  compute  the 
spacecraft  characteristics.  These  were  carried  out  on  an  Excel  spreadsheet.  The  calculations 
took  only  seconds,  and  were  repeated  for  a  wide  variety  of  presumed  user  utilities. 

The  results  revealed  key  constraints,  trades,  and  promising  types  of  designs.  Chemical  fueled 
tugs  were  severely  limited,  especially  for  higher-energy  missions  such  as  GEO  transfer  rescues, 
by  the  specific  impulse  of  the  fuel.  Alternate  propulsion  concepts  had  other  limits:  electric 
propulsion  (which  is  slow)  was  highly  sensitive  to  the  assumed  utility  of  timely  response,  and 
nuclear  propulsion  results  in  high  base  costs.  Independent  of  propulsion  system,  low  weight 
grappling,  observation,  and  control  equipment  was  always  desirable. 

The  tradespace  analysis  reveals  three  classes  of  potentially  useful  space  tug  vehicles.  The 
Electric  Cruiser  occupies  the  “knee  in  the  curve”  for  our  nominal  utilities,  providing  good  value 
for  cost.  The  “Nuclear  Monster”  is  only  design  that  can  meet  a  desire  for  a  high  delta- V,  high 
capability,  rapid  response  system;  electric  monsters  (not  shown)  might  be  interesting  to  users  not 
interested  in  rapid  response  time.  A  final  range  of  vehicles  occupies  the  lower  left  region  of  the 
Pareto  front.  These  are  cost  effective  vehicles  build  using  existing  technology  (e.g.  storable  bi¬ 
propellant  systems)  that  can  do  a  variety  of  jobs  requiring  lower  delta- V.  They  could,  for 
example,  tend  set  of  vehicles  in  similar  orbits,  doing  a  variety  of  maintenance  tasks.  For  this 
reason  (and  to  extend  the  naval  support  vessel  metaphor)  they  have  been  dubbed  “Tenders.” 

The  MATE  trade  space  was  used  to  drive  an  ICE  session  to  design  a  variety  of  tug  vehicles. 
Several  “cruiser”  vehicles  were  designed.  From  on  or  near  the  Pareto  front,  electric  cruisers  such 
as  the  one  shown  in  Error!  Reference  source  not  found,  were  designed.  High  delta- V 
chemical  propulsion  vehicles  are  not  optimal  according  the  MATE  analysis;  the  ICE  results 
(which  had  difficulty  closing  because  of  extreme  fuel  loads)  helped  to  illustrate  why.  Finally,  a 
variety  of  Tender  vehicles  were  designed;  some  for  specific  missions  and  some  for  generic 
service;  these  designs  showed  that  a  modular  approach  to  tender  vehicle  design  might  be  the  best 
approach.11 
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Final  Report  for  “Orbital  Express  Architecture  and  Trade  Space  Studies,”  a  subcontract  to 
Metis  Design  Corporation. 

Hugh  McManus,  Principal  Investigator 

The  work  done  under  this  subcontract  was  focused  on  the  creation  of  a  unified  report  or  book  to 
summarize  the  progress  made  in  the  Multi-attribute  Tradespace  Exploration  (MATE)  method  to 
date,  and  the  creation  of  new  content  as  necessary  to  assure  the  relevance  of  this  document  to  the 
problems  of  infrastructure  systems  such  as  Orbital  Express  (OE).  The  aim  of  the  book  is  the 
dissemination  of  advanced  tradespace  methods.  These  methods  will  be  very  useful  to  Orbital 
Express  and  similar  space  infrastructure  systems.  They  will  provide  a  method  for  both  the  front- 
end  design  of  infrastructure  systems,  and  for  consideration  of  the  value  and  uses  of  space 
infrastructure  when  designing  other  systems.  To  assure  relevance  one  of  the  two  examples 
running  through  the  book  is  a  simple  orbital  transfer  vehicle,  or  “space  tug,”  of  the  sort  that 
would  be  useful  component  of  an  OE  system. 

Specific  tasks  were  carried  out  under  this  subcontract  out  in  the  context  of  creating  the  proposed 
book.  They  included: 

1.  Mental  model  for  MATE  application 

This  task  involved  creation  of  a  framework  for  comparing  MATE  and  conventional  front-end 
methods.  The  front  end  of  the  product  development  process  model  of  Ulrich  and  Eppinger111  was 
expanded  to  create  a  simple,  intuitive  “mental  model”  of  the  irreducible  steps  necessary  to 
initiate  a  product  development.  Using  this  model,  current  processes  and  the  MATE  process  could 
be  compared,  and  the  advantages  of  the  later  expressed  in  simple  tenns.  The  result  is  both  a 
teaching  tool,  and  a  guide  to  understanding  how  MATE  can  be  applied  to  areas  outside  of  simple 
product  design,  i.e.  for  higher-level  application  such  as  systems  architecture  or  system-of- 
systems  work.  It  also  clarifies  the  advantages  of  MATE  for  systems  without  easily  defined 
traditional  requirements,  e.g.  infrastructure  systems. 

2.  Architectural  applications  of  MATE 

A  study  was  undertaken  to  relate  MATE  to  current  practice  in  systems  architecting.  It  has  been 
pointed  out  that  MATE,  although  it  has  been  applied  to  a  wide  variety  of  systems,  has  primarily 
been  used  in  the  preliminary  design  of  the  physical  architecture  of  space  vehicles.  This  task 
attempted  to  clarify  the  use  of  MATE  for  higher-level  architectural  decision  as  well. 

Architectural  frameworks  such  as  DoDAF  and  MODAF  were  surveyed.  A  brief  description  of 
DoDAF  was  included  in  the  document,  and  a  partial  DoDAF  description  of  the  space  tug  system 
was  created.  The  DoDAF  and  related  descriptive  tools  (e.g.  the  CORE  software)  were  found  to 
be  complementary  to  MATE  analysis.  A  set  of  current  practices  (e.g.  standards,  heuristics, 
individual  expertise,  and  various  Systems  Engineering  methodologies)  were  also  briefly 
surveyed.  Basic  difficulties  with  the  current  practice,  and  ways  in  which  MATE  may  address 
them,  are  presented. 
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The  mental  model  developed  in  task  1  above  was  used  to  clarify  the  distinctions  between  the 
preliminary  design  applications  for  which  MATE  has  been  successfully  used,  and  the  challenges 
at  an  architecture  level.  These  will  depend  on  the  specifics  of  the  system,  but  some 
generalizations  can  be  made: 

•  If  the  architectural  decision  can  be  parameterized  (how  many  vehicles  to  use)  or  reduced 
to  discrete  choices  that  result  in  different  parameters  in  the  same  basic  system  model 
(what  kind  of  propulsion  to  use),  then  the  MATE  method  may  be  used  “as  is”  for 
architectural  trades  space  exploration.  Simple  examples  of  this  kind  have  been  analyzed 
using  MATE  in  previous  work. 

•  If  the  architecture  decisions  require  choices  that  change  the  models  used  to  calculate 
system  performance  (e.g.  propulsion  choice  changes  orbital  calculations  (electric)  or 
vehicle  dynamics  (tethers))  the  MATE  method  may  be  used  with  additional  effort. 
Clearly,  practical  limits  may  be  reached  if  large  numbers  of  models  are  required.  In  trade 
space  terminology,  these  cases  involve  changes  to  the  composition  (not  just  the 
enumeration)  of  the  design  vectors.  In  this  case,  the  MATE  method  may  be 
supplemented  productively  by  Object-Process  Methods;  the  work  of  Koolv  in  analyzing 
the  wide  variety  of  Apollo  architecture  options  is  instructive. 

•  If  the  architectural  decisions  involve  multiple  stakeholders,  especially  if  they  are  working 
at  cross  purposes,  have  poorly  defined  needs,  or  are  diffuse,  the  MATE  method  is 
challenged.  Defining  meaningful  objective  function  may  be  difficult.  In  trade  space 
tenns,  the  set  of  attributes  may  become  large,  and  the  set  of  utilities  (for  each  attribute, 
for  each  stakeholder)  may  become  large  and  incompletely  defined.  This  problem  is  not 
intractable,  but  presents  difficulties.  There  is  currently  no  named  methodology  for 
dealing  with  this  class  of  problems,  although  there  are  examples;  the  work  of  Rebentisch 
is  instructive. v 

3.  MATE-CON  method  description  update. 

An  existing  description  of  the  MATE  method  and  associated  use  of  concurrent  engineering  (- 
CON)  was  updated.  Perhaps  the  most  interesting  addition  was  a  comparison  between  the  two 
running  examples  used  in  the  original  document,  which  were  developed  as  student  projects,  and 
similar  systems  that  have  subsequently  undergone  detailed  design  and/or  been  launched  in  the 
real  world.  The  remarkable  agreement  in  both  cases  lends  confidence  in  the  method. 

4.  Integration  of  methods  for  the  handling  of  uncertainty  using  MATE 

This  task  represented  the  majority  of  the  work  under  this  contract.  In  the  early  stages  of  a  design 
process,  there  are  many  uncertainties  as  to  how  technology,  budgets,  and  user  needs  will  evolve 
over  the  lifetime  of  the  program.  These  uncertainties  include  both  risks  and  opportunities;  in 
particular,  markets  may  change  in  ways  favorable  to  a  robust  or  versatile  system.  The  full  range 
of  these  uncertainties,  their  possible  risks  (or  opportunities),  mitigating  (or  exploiting)  strategies, 
and  possible  outcomes  in  terms  of  system  performance  are  organized  in  a  framework  developed 
previously  by  McManus  and  Hastings/1  This  framework  helps  organize  thinking  about  many 
sorts  of  uncertainties,  but  is  not  a  tool  for  actually  evaluating  them.  In  this  work,  the  framework 
was  tied  into  the  MATE  method  to  provide  a  guide  to  both  including  uncertainties  in  the 
tradespace  analyses,  and  depicting  uncertainties  on  the  tradespace  as  one  of  the  factors  that  the 
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decision-makers  need  to  consider.  The  result  is  a  method  for  handling  uncertainties  as  part  of 
tradespace  exploration. 

Understanding  uncertainties  is  critical  both  to  the  understanding  of  orbital  infrastructure  projects 
(which  are  beset  with  uncertainties  of  all  types),  and  for  planning  programs  that  may  use  orbital 
infrastructures.  It  has  been  demonstrated  previously  that  a  primary  value  created  by  these 
infrastructures  is  the  management  of  both  risk  (downside  uncertainty)  and  opportunities 
(upgrades  and  the  like  -  the  upside  of  uncertainty)  for  client  systems. 

The  proposed  method  considers  three  basic  aspects  of  uncertainty: 

4a)  Uncertainty  IN  the  systems  on  the  tradespace 

The  first  types  of  uncertainty  analyses  proposed  in  the  framework  are  the  use  of  suitable  margins 
(incorporated  into  rules  of  thumb  in  the  analysis)  and  component  reliability  (e.g.  Markov  model) 
analyses.  The  first  is  an  essential  element  of  any  reasonable  conceptual  design  work.  The  later 
is  sometimes  either  neglected  or  is  difficult  to  formalize.  For  example,  in  very  simple  models, 
with  “black  box”  models  of  even  major  components,  estimating  their  reliability  involves  a  fair 
bit  of  guesswork.  This  problem  persists  into  more  detailed  models,  but  becomes  more  tractable 
and  amenable  to  solution  using  existing  tools;  by  the  time  the  analysis  has  moved  to  a  concurrent 
engineering  model,  a  reliability  “chair”  should  be  standard  practice/11 

If  reliability  is  incorporated  into  the  evaluation  of  the  designs  in  the  tradespace  its  effect  will  be 
to  make  the  attributes  of  the  system  probabilistic;  they  will  only  be  achieved  at  the  predicted 
level  if  the  system  remains  functional.  There  is  some  chance  the  attributes  will  be  degraded  or 
not  achieved  at  all.  For  the  “end  user”  stakeholder  who  defines  most  or  all  of  the  technical 
aspects  of  the  system  (at  least  in  most  cases),  this  probabilistic  reduction  in  the  expected  value  of 
the  attribute  should  result  in  a  proportional  loss  of  utility.  The  cumulative  effect  of  lost  utility  is 
to  move  the  points  on  the  tradespace  somewhat.  This  movement  will  affect  decision  to  the 
extent  it  is  uneven  -  intrinsically  less-reliable  systems  will  be  selected  against. 

Due  to  the  assumptions  made  when  measuring  the  utilities,  it  is  methodologically  unsound  to 
treat  the  reliability  itself  as  a  separate  attribute  for  the  end-user.  However,  there  are  multiple 
stakeholders  (e.g.  career  minded  program  managers,  holders  of  portfolios  of  systems,  high  level 
planners  of  capabilities)  for  whom  program  reliability  is  an  important  and  (for  them)  independent 
attribute.  For  these  stakeholders,  the  calculated  reliability  needs  to  be  considered  explicitly.  This 
is  not  in  itself  a  new  idea,  although  most  previous  presentations  have  considered  reliability 
presented  against  a  single  metric  of  performance,  and  perhaps  cost/111  In  the  MATE  formulation, 
it  becomes  another  attribute,  although  like  cost  one  which  should  not  under  most  circumstances 
be  combined  with  the  other  attributes  using  multi-attribute  techniques.  A  simple  example 
calculation  based  on  a  small  experimental  satellite  is  used  to  illustrate  how,  for  some 
stakeholders,  reliability  considerations  may  lead  to  system  architectures  rather  different  than 
those  that  seem  optimal  to  the  other  stakeholders.  This  can  set  up  a  classic  case  of  stakeholders 
with  conflicting  utilities,  which  can  only  be  resolved  through  negotiation. 

4b)  Uncertainty  depicted  ON  the  tradespace. 


19 


More  complex  uncertainty  effects  may  be  represented  explicitly  on  the  tradespace.  Good 
practice  of  the  MATE  techniques  calls  for  technical  parameters  in  the  tradespace  models  to  be 
represented  not  by  “hardwired”  values  (or  worse,  modeling  assumptions),  but  rather  be 
incorporated  into  a  “constants  vector.”  Technological  and  development  uncertainties  thus  enter 
the  tradespace  models  via  uncertainties  in  the  values  in  this  vector.  This  allows,  at  a  minimum, 
sensitivity  studies  to  be  carried  out  to  capture  dangerous  sensitivity  to  possibly  uncertain 
parameters.  This  should  be  considered  good  practice  in  tradespace  analysis  even  without  further 
consideration  of  uncertainties. 

More  interesting  is  use  of  varying  elements  in  the  constants  vector  to  calculate  the  resulting 
variability  of  the  results  on  the  tradespace.  Although  this  could  theoretically  be  done  using 
statistical  moment  or  interval  methods,  Monte  Carlo  methods  are  well  suited  to  tradespace 
analyses.  They  require  multiple  runs  of  the  model  with  various  combinations  of  randomly-varied 
parameters,  but  these  models  must  be  efficient  to  be  used  in  the  tradespace  analysis  in  the  first 
place,  so  the  computational  effort  should  be  tractable.  The  simplest  way  to  show  these  on  the 
tradespace  is  by  distribution  “clouds,”  although  bounds  or  best/worst  endpoints  could  also  be 
used.ix,x 

The  same  method  may  be  used  to  express  user  need  uncertainty  by  varying  the  elements  of  the 
multi-attribute  utility  model  in  a  similar  way.  The  space  tug  example  is  extended  to  include  both 
technical  and  user  need  uncertainty,  and  the  resulting  tradespace  explored.  The  example  proves 
quite  rich,  illustrating  several  different  kinds  of  technical  uncertainty,  and  both  downside  risk 
and  upside  opportunity  uncertainties  created  by  uncertain  user  needs.  As  with  “static”  tradespace 
exploration,  the  presentation  of  the  uncertainties  is  the  beginning  of  the  process  of  interrogating 
the  full  set  of  tradespace  data  to  determine  the  root  causes  of  the  uncertainties.  This  fundamental 
knowledge  is  the  real  value  gained  by  using  the  extended  MATE  method. 

The  proposed  method  would  be  a  key  tool  for  users  of  orbital  services,  as  it  highlights  in  the  first 
stages  of  system  design  key  uncertainties  and  their  causes.  If  these  uncertainties  cannot  be 
mitigated  on  the  ground,  they  become  candidates  for  on-orbit  service  mitigation,  or  (through 
upgrades)  exploitation.  Several  existing  examples  of  this  kind  of  analysis  are  referenced. 

4c)  The  evolving  tradespace 

The  final  approach  to  uncertainty  is  to  consider  its  evolution  with  time,  and  the  corresponding 
possibility  that  the  design  can  evolve  as  the  situation  changes.  As  time  passes,  some 
uncertainties  are  reduced  (i.e.  things  that  were  not  know  become  known)  while  others  may 
become  larger,  or  evolve  such  that,  for  example,  a  future  mean  value  turns  out  to  be  outside  of 
the  initially  expected  range. 

The  use  of  real  options  techniques  to  allow  the  hedging  of  future  risks  by  investing  in  chance  to 
react  at  some  time  in  future  is  reasonably  developed.  Its  impact  on  tradespace  analysis  is  to  add 
an  additional  dimension  to  the  uncertainty  calculations  (time),  and  several  additional 
complications  to  the  design  vector  (future  upgrade  paths,  and  investments  in  options  that  may 
simplify  these  upgrades).  Finally,  in  a  rough  analogy  to  the  use  of  reliability  as  an  “attribute” 
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representing  the  possible  degradation  of  the  performance,  an  attribute  or  attributes  of 
“flexibility”  may  be  desired.  This  would  simplify  the  representation  of  the  collected  system 
attributes’  ability  to  remain  near-optimal  as  user  needs,  technologies,  or  other  uncertain  factors 
changed. 

There  is  not  a  “one-size  fits  all”  solution  (yet)  to  this  challenge,  but  several  cases  are  explored 
which  provide  some  guidance  for  how  to  implement  analyses  of  evolving  tradespaces.  The  work 
of  Durleth,xl  Roberts, xn  and  Nichiani™1  are  used  as  examples  in  representing  flexibility  on  the 
tradespace.  A  final  use  of  the  spacetug  example  illustrates  a  possible  generalization  of  the 
method. 
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